home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19971216-19980424 / 000071_news@newsmaster….columbia.edu _Thu Jan 8 16:53:06 1998.msg < prev    next >
Internet Message Format  |  2020-01-01  |  3KB
  1. Return-Path: <news@newsmaster.cc.columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id QAA12288
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Thu, 8 Jan 1998 16:53:05 -0500 (EST)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id QAA03040
  7.     for kermit.misc@watsun; Thu, 8 Jan 1998 16:53:05 -0500 (EST)
  8. Newsgroups: comp.protocols.kermit.misc
  9. Path: news.columbia.edu!panix!howland.erols.net!ix.netcom.com!gerlach
  10. From: gerlach@netcom.com (Matthew H. Gerlach)
  11. Subject: Re: Kermit vs SCO pttys
  12. Message-ID: <gerlachEMHJ12.D4B@netcom.com>
  13. Organization: Netcom Online Communications Services (408-241-9760 login: guest)
  14. References: <69339l$1ksa$1@newssvr03-int.news.prodigy.com>
  15. Date: Thu, 8 Jan 1998 21:43:49 GMT
  16. Lines: 41
  17. Sender: gerlach@netcom18.netcom.com
  18. Xref: news.columbia.edu comp.protocols.kermit.misc:8241
  19.  
  20. I'm not sure how relevent my experience is, but here goes.  I have used
  21. Expect and a Perl functional equivelent to "talk" to kermit running
  22. on SCO 3.2.4.  Both Expect and Perl's functional equivent use ptys for this
  23. "talking".  In the process of doing this, I've noticed a few important
  24. items.  First and formost, shuting down kermit gracefully really helps.
  25.  
  26. Secondly, a very common problem is that if you don't gracefully shutdown
  27. kermit, but "kill" it, you must be sure to reap the dead with a call
  28. to the wait() function.  If you don't there will be zombies floating around,
  29. and you could run out of ptys and processes.  However, when your parent
  30. progam exits, UNIX will do the reaping for you; so a post mortem won't tell
  31. you of the problem.
  32.  
  33. Matthew H. Gerlach
  34. In article <69339l$1ksa$1@newssvr03-int.news.prodigy.com> GXXE75A@prodigy.com (Morgan Johnson) writes:
  35. >I am using C-Kermit to control unattended data transfers from several 
  36. >remote Unix systems and one central Unix system.  All systems are SCO 3.2.
  37. >4.2.  I am using Kermit since some systems are on a network and some 
  38. >require dialup, and Kermit gives me a consistent interface.
  39. >
  40. >On the networked machines, the remote system assigns a ptty to handle the 
  41. >kermit connection.  For some reason, these pttys are not being released 
  42. >for re-use.  E.G.: one of the systems was rebooted at the end of 1/6.  
  43. >Since then there have been six connections made using C-Kermit, and at 
  44. >this time ttyp0-5 are no longer available.  When I telnet in, or use 
  45. >Kermit, the system assigns me ttyp6.  It does this consistently, and does 
  46. >NOT advance the ptty number, which is to say, I cannot recreate the 
  47. >problem.  I have tried breaking the connection in various nasty ways, I 
  48. >have checked for lingering processes, I have reviewed the streams 
  49. >resources, etc., checked the ownership and permissions on the pttys, etc.,
  50. > etc. Normal telnet connections never cause the problem, but every Kermit 
  51. >connection made at night does cause it.
  52. >
  53. >Any ideas?
  54. >
  55. >Morgan Johnson, GXXE75A@prodigy.com
  56. >
  57.  
  58.